Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cramertj (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Good catch! I was worried it'd be an additional check, but 👍 for tweaking the existing one.

r? @scottmcm
@bors r+ rollup

📌 Commit 181d811 has been approved by scottmcm

@bors r-

Oops, didn't notice that CI is failing.

It looks like this is adding a new branch in https://github.com/rust-lang/rust/blob/master/src/test/codegen/vec-clear.rs -- probably it was previously inlining the .truncate(0) and 0 > self.len used to be impossible. You'll need to take a look at the history of that test and see what it's trying to ensure.

@bors r-

Oops, didn't notice that CI is failing.

It looks like this is adding a new branch in https://github.com/rust-lang/rust/blob/master/src/test/codegen/vec-clear.rs -- probably it was previously inlining the .truncate(0) and 0 > self.len used to be impossible. You'll need to take a look at the history of that test and see what it's trying to ensure.

The linked test(?) doesn't look like it has any kind of assertion and I don't know what //CHECK-NOT load means, I'm completely lost; I have no idea how to fix this.

That's a codegen test using FileCheck, https://llvm.org/docs/CommandGuide/FileCheck.html#tutorial

It'll need either changing the test or changing the code so that .clear() doesn't branch on the current length. The OP here sounds like you were expecting the addition of the branch in clear, so maybe look at the test history to see why there's a test saying that there shouldn't be one.

FWIW this was previously attempted in #74172

Fixes #76089.

@flotts Ping from triage, would you mind addressing the comments above? If you need some help, you can visit the rust-lang.zulipchat.com and seek for some help there. Thanks!

@flotts Ping from triage, would you mind addressing the comments above? If you need some help, you can visit the rust-lang.zulipchat.com and seek for some help there. Thanks!

I've been pretty swamped between school and work, I didn't expect this problem to be so complicated to solve, and I don't want to make changes to tests without sufficient understanding of the implications of those changes. Frankly, it makes no sense to me that there's a new branch as a result of this code.

I would recommend someone simply close this and give up for now or something. Maybe another time, if someone else doesn't fix it first. It clearly isn't a proper solution to this issue :P

Frankly, it makes no sense to me that there's a new branch as a result of this code.

For anyone else who arrives and looks at this: this can happen because the old code, after inlining, resulted in if 0 > some_unsigned_number, which is of course never possible and thus gets optimized away. Changing the code so that the check is >= makes it possible again, and thus it is no longer optimized out.